Implementing workflow field formulas

ABSTRACT

The efficiency and versatility for the implementation of formulas in an on-demand database is improved. Formulas are categorized. Based at least partly on the categorization, formulas are evaluated synchronously or asynchronously. An asynchronous evaluation may be performed if a certain set of criteria is not satisfied. Asynchronous evaluations may be performed using a queue. During an asynchronous update of an object, a counter field and/or an estimate field may be used respectively for indicating the consistency of values of the object and a time when the values were consistent. The versatility of formulas is enhanced by using a formula to create a default value for a custom field when it is created and to determine whether an action is to be performed, and is enhanced by having an action define when a formula is to be updated.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application claims priority from and is a continuationapplication of U.S. application Ser. No. 13/346,657 entitled“IMPLEMENTING WORKFLOW FIELD FORMULAS” filed Sep. 1, 2009, which is adivisional application of U.S. Pat. No. 7,814,052 (U.S. application Ser.No. 12/877,991) entitled “IMPLEMENTING FORMULAS FOR CUSTOM FIELDS IN ANON-DEMAND DATABASE” filed Sep. 8, 2010, which is a divisional of U.S.Pat. No. 7,814,052 entitled “Implementing Formulas For Custom Fields InAn On-Demand Database” filed Nov. 3, 2006, the entire contents of whichare herein incorporated by reference for all purposes.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

The present invention relates generally to implementing formulas indatabase systems, and more particularly to implementing formulas forcustom fields in an on-demand database.

BACKGROUND

In modern database systems, users may be able to define a formula thatspecifies how to compute a new field from other fields. For example, adiscount price formula field might be computed from a base price fieldand a discount percent field. Traditionally, this approach has workedwell with conventional databases, in which formulas can be efficientlyevaluated since most relevant data is relatively concentrated andbecause the sizes of the databases are relatively small.

However, as database systems become larger and store many objects, thedata stored in the database may become quite dispersed. Thus, theimplementation of formulas in a large database can demand much morecomputing resources to retrieve such dispersed data. Also, formulas maybe unnecessarily evaluated or evaluated in an untimely fashion, leadingto inefficiency and waste of computing resources. In database systems inwhich one or more customers may share the various elements of hardwareand software of the database system, these problems become compounded asindividuals' demand on the system may cause further dispersion orfractionalization of data distribution throughout the database.

Therefore, it is desirable to provide methods and systems for efficientand versatile implementation of formulas in databases.

BRIEF SUMMARY

In embodiments, systems and methods for implementing formulas for customfields in an on-demand database are provided. These systems and methodscan determine a way to evaluate a formula of a given type from amongdifferent ways to evaluate different types of formulas. The ability todetermine a way for evaluating a formula can enable embodiments toprovide more efficient formula evaluations when used in conjunction withone or more of on-demand database services, large databases andmulti-tenant database architectures.

Embodiments can employ one or more techniques such as for example andwithout limitation: classifying formulas based on criteria andevaluating the formulas synchronously or asynchronously based on theclassifications, asynchronously evaluating formulas using a queue,providing default value formulas for custom fields, executing an actiononly after a validation formula has returned the desired result, and/orevaluating a formula only right after a specific action occurs.Employing one or more of these techniques can enable embodiments toefficiently implement formulas and manipulate data in a multi-tenantenvironment.

A database can generally be viewed as a collection of objects, such as aset of logical tables, containing data fitted into predefinedcategories. A “table” is one representation of a data object, and isused herein to simplify the conceptual description of objects and customobjects according to the present invention. It should be understood that“table” and “object” may be used interchangeably herein. As used herein,the term on-demand database refers to a web-enabled application thatallows one or more users to access one or more databases as a serviceeither via the Internet or some other remote communications mechanism.As used herein, the term multi-tenant database system refers to adatabase system implementing a multi-tenant architecture that enablescustomer organizations (i.e., tenants) to share applications and data,and database resources, in one logical database. In multi-tenantdatabase environments, even the database tables themselves can be sharedacross the tenants. For example, each entity in the data model couldcontain an organization_id column that distinguishes rows for eachtenant. Queries and data manipulation in the context of a tenant filteron this (indexed) organization_id column to ensure proper security andthe appearance of virtual private databases. This strategy enablesmulti-tenant database embodiments to be able to expose standard entitiessuch as for example and without limitation, Account, Contact, Lead, andOpportunity entities to customers.

As used herein, a formula may be comprised of one or more expressions,each giving a result such as a value or condition, which are combined togive a result. The term synchronous is used herein to signify that aformula is evaluated when one or more input values to the formula arechanged. The term asynchronous is used herein to signify that a formulais evaluated by a scheduling module after one or more input values ofthe formula have been changed. The term update refers to a subsequentevaluation of a formula that had been previously evaluated.

According to an embodiment and by way of example, systems and methodscan determine from among different ways to evaluate different types offormulas a way to evaluate a formula of a given type. For example, oncea formula is defined and is used to obtain a first result, a change inthe input data of the formula is received. A determination may be madeas to whether the formula accesses input data from only one row of adatabase table or input data from at least two rows of one or moredatabase tables. If the formula accesses data from only one row, theone-row formula may be synchronously evaluated to obtain a secondresult. If the formula accesses data from at least two rows, a decisionmay be made whether to evaluate the multiple-row formula synchronouslyor asynchronously to obtain a second result. In various aspects, thesedecisions may be based on an amount of input data to the formula, acurrent performance load on the database system, and/or the number ofsynchronous evaluations previously done for a user or tenant.Embodiments may also synchronously evaluate the multiple-row formulawhen the second result is computable with a delta value.

According to another embodiment, systems and methods for updating aformula in a database system are provided. For example, after a userrequests an update of a formula, a query including a set of one or morecriteria is submitted to the database. The criteria are analyzed todetermine whether the criteria are satisfied. If the criteria aresatisfied, the formula is updated synchronously. If the criteria are notsatisfied, the formula is updated asynchronously. An asynchronous updatemay comprise adding the update request as a first item to a queue,evaluating formulas associated with one or more other items previouslyadded to the queue, and subsequently evaluating the first item to obtainthe first result. Further, embodiments may perform other actions such aswithout limitation, blocking additional update requests for the formulauntil the first item is evaluated, storing the first result in thedatabase at a specific record of a custom field, and indicating aninconsistency between backing data of the first formula and a customfield value.

In an embodiment, an indication of an inconsistency is provided. Acounter field of an object having a custom field associated with theformula is provided. The counter field is incremented when requests toupdate the formula are added to the queue and decremented when theformula is evaluated for an item in the queue. The indication of aninconsistency may be achieved using with a staleness flag, shading,icons, or a link to more status information. The indication may bedisplayed for an object if any custom field value of that object has aninconsistency.

According to another embodiment, systems and methods estimate a timewhen custom field values of an object in a database were consistent withother data in the database. A formula receives an input from a portionof the other data and produces a result used for the custom field value.Typically, a request to update a custom field value of the object isreceived and added as a first item to a queue as part of an asynchronousupdate of the formula. A first time associated with the first item isstored. Additional items associated with the object may be added to thequeue, where a time is associated with each item. The formula of thefirst item is evaluated as part of a de-queuing process, and the firsttime is copied into the estimate field. In an embodiment where an objecthas a counter field, when the counter field is zero prior to adding thefirst item to the queue, the first time may be copied to the estimatefield when the first item is added to the queue.

According to another embodiment, systems and methods for displaying anew custom field in a database are provided. For example, a request tocreate a custom field having one or more custom field values isreceived; one or more default formulas may be evaluated to obtain one ormore results. The custom field values may be populated with the resultsand the custom field values may be displayed.

According to another embodiment, systems and methods of processing arequest for a field of a database are provided. For example, a requestfor an action, such as a save, associated with the field is received. Aformula associated with the field is evaluated to obtain a Booleanresult. If the Boolean result is a first value, the requested action isperformed. If the Boolean result is a second value, the requested actionis not performed. In one embodiment, each of the expression of theformula must be valid for the first value to be returned. In anotherembodiment, the first value is returned even though not all of theexpressions are valid. A formula may be associated with a specificdatabase record or a plurality of records. Also, if the Boolean resultis the second value, an error message may be displayed.

According to another embodiment, systems and methods of storing a customfield value in a database are provided. For example, an action isreceived as part of a workflow process. Based on the receipt of theaction, a formula is updated to obtain the custom field value.Subsequent updates of the formula may be prevented when input values forthe formula change.

Reference to the remaining portions of the specification, including thedrawings and claims, will realize other features and advantages of thepresent invention. Further features and advantages of the presentinvention, as well as the structure and operation of various embodimentsof the present invention, are described in detail below with respect tothe accompanying drawings. In the drawings, like reference numbersindicate identical or functionally similar elements.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present invention will bedescribed with reference to the drawings, in which:

FIG. 1 illustrates an environment wherein a multi-tenant database systemmight be used;

FIG. 2 illustrates elements of FIG. 1 and various interconnectionsbetween the elements;

FIG. 3 illustrates an example of objects represented as a table that hascustom fields defined with formulas and that may benefit from oneembodiment;

FIG. 4 illustrates a classification of formulas according to oneembodiment;

FIG. 5 illustrates a flowchart for a method of evaluating a formula in adatabase according to one embodiment;

FIG. 6 illustrates a flowchart for a method of updating a formula in adatabase according to one embodiment;

FIG. 7 illustrates a flowchart for a method of asynchronously updating aformula in a database according to one embodiment; and

FIG. 8 illustrates a flowchart for a method of determining a time when adatabase field was last correct according to one embodiment.

DETAILED DESCRIPTION

Embodiments in accordance with the present invention provide systems andmethods for implementing formulas in a multi-tenant database networkenvironment. Embodiments describe a family of techniques forimplementing formulas that may occur, for example, in the applicationlayer that sits in front of a conventional database. To ensure efficientuse of resources, embodiments may reduce the consistency guarantees ofdata resulting from formulas and return formula field values that areout-of-date. This is particularly true for formulas that have input datafrom multiple rows, which is more likely to occur in a MTS.

Embodiments can provide an on-demand database that allows users todefine a formula that specifies how to compute a new field from otherfields. For example, a discount price formula field might be computedfrom a base price field and a discount percent field. In on-demandapplications, the database is shared by many customers and efficiencybecomes more important. The application should not use demandcomputational resources for a single customer to the detriment of othercustomers. By contrast, single tenant databases are usually able toevaluate formulas efficiently, since most relevant data is relativelyconcentrated and because the sizes of the databases are relativelysmall.

Because a multi-tenant database system (MTS) can be quite large withmany objects belonging to a single tenant or organization, and data maybe quite dispersed, implementation of formulas in an MTS can demand agreater number of computing resources to retrieve such dispersed data.Techniques for effectively implementing formula evaluation inmulti-tenant and on-demand databases will next be described withreference to example embodiments.

I. A Multi-Tenant Database System (MTS)

FIG. 1 illustrates an environment wherein a multi-tenant database systemmight be used. As illustrated in FIG. 1 (and in more detail in FIG. 2)any user systems 12 might interact via a network 14 with a multi-tenantdatabase system (MTS) 16. The users of those user systems 12 might beusers in differing capacities and the capacity of a particular usersystem 12 might be entirely determined by the current user. For example,where a salesperson is using a particular user system 12 to interactwith MTS 16, that user system has the capacities allotted to thatsalesperson. However, while an administrator is using that user systemto interact with MTS 16, that user system has the capacities allotted tothat administrator.

Network 14 can be a LAN (local area network), WAN (wide area network),wireless network, point-to-point network, star network, token ringnetwork, hub network, or other configuration. As the most common type ofnetwork in current use is a TCP/IP (Transfer Control Protocol andInternet Protocol) network such as the global internetwork of networksoften referred to as the “Internet” with a capital “I,” that will beused in many of the examples herein, but it should be understood thatthe networks that the present invention might use are not so limited,although TCP/IP is the currently preferred protocol.

User systems 12 might communicate with MTS 16 using TCP/IP and, at ahigher network level, use other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. As an example, where HTTPis used, user system 12 might include an HTTP client commonly referredto as a “browser” for sending and receiving HTTP messages from an HTTPserver at MTS 16. Such HTTP server might be implemented as the solenetwork interface between MTS 16 and network 14, but other techniquesmight be used as well or instead. In some implementations, the interfacebetween MTS 16 and network 14 includes load sharing functionality, suchas round-robin HTTP request distributors to balance loads and distributeincoming HTTP requests evenly over a plurality of servers. Preferably,each of the plurality of servers has access to the MTS's data, at leastas for the users that are accessing that server.

In certain aspects, the system shown in FIG. 1 implements a web-basedcustomer relationship management (CRM) system. For example, in oneaspect, MTS 16 can include application servers configured to implementand execute CRM software applications as well as provide related data,code, forms, web pages and other information to and from user systems 12and to store to, and retrieve from, a database system related data,objects and web page content. With a multi-tenant system, tenant data ispreferably arranged so that data of one tenant is kept separate fromthat of other tenants so that one tenant does not have access toanother's data, unless such data is expressly shared.

One arrangement for elements of MTS 16 is shown in FIG. 1, including anetwork interface 20, storage 22 for tenant data, storage 24 for systemdata accessible to MTS 16 and possibly multiple tenants, program code 26for implementing various functions of MTS 16, and a process space 28 forexecuting MTS system processes and tenant-specific processes, such asrunning applications as part of an application service.

Several elements in the system shown in FIG. 1 include conventional,well-known elements that need not be explained in detail here. Forexample, each user system 12 could include a desktop personal computer,workstation, laptop, PDA, cell phone, or any WAP-enabled device or anyother computing device capable of interfacing directly or indirectly tothe Internet or other network connection. User system 12 typically runsan HTTP client, e.g., a browsing program, such as Microsoft's InternetExplorer™ browser, Netscape's Navigator™ browser, Opera's browser, or aWAP-enabled browser in the case of a cell phone, PDA or other wirelessdevice, or the like, allowing a user (e.g., subscriber of a CRM system)of user system 12 to access, process and view information and pagesavailable to it from MTS 16 over network 14. Each user system 12 alsotypically includes one or more user interface devices, such as akeyboard, a mouse, touch screen, pen or the like, for interacting with agraphical user interface (GUI) provided by the browser on a display(e.g., monitor screen, LCD display, etc.) in conjunction with pages,forms and other information provided by MTS 16 or other systems orservers. As discussed above, the present invention is suitable for usewith the Internet, which refers to a specific global internetwork ofnetworks. However, it should be understood that other networks can beused instead of the Internet, such as an intranet, an extranet, avirtual private network (VPN), a non-TCP/IP based network, any LAN orWAN or the like.

According to one embodiment, each user system 12 and all of itscomponents are operator configurable using applications, such as abrowser, including computer code run using a central processing unitsuch as an Intel Pentium processor or the like. Similarly, MTS 16 (andadditional instances of MTS's, where more than one is present) and allof their components might be operator configurable using application(s)including computer code run using a central processing unit such as anIntel Pentium processor or the like, or multiple processor units.Computer code for operating and configuring MTS 16 to intercommunicateand to process web pages and other data and media content as describedherein is preferably downloaded and stored on a hard disk, but theentire program code, or portions thereof, may also be stored in anyother volatile or non-volatile memory medium or device as is well known,such as a ROM or RAM, or provided on any media capable of storingprogram code, such as a compact disk (CD) medium, digital versatile disk(DVD) medium, a floppy disk, and the like. Additionally, the entireprogram code, or portions thereof, may be transmitted and downloadedfrom a software source, e.g., over the Internet, or from another server,as is well known, or transmitted over any other conventional networkconnection as is well known (e.g., extranet, VPN, LAN, etc.) using anycommunication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet,etc.) as are well known. It will also be appreciated that computer codefor implementing aspects of the present invention can be implemented inany programming language that can be executed on a server or serversystem such as, for example, in C, C++, HTML, Java, JavaScript, anyother scripting language, such as VBScript and many other programminglanguages as are well known.

According to one embodiment, each MTS 16 is configured to provide webpages, forms, data and media content to user systems 12 to support theaccess by user systems 12 as tenants of MTS 16. As such, MTS 16 providessecurity mechanisms to keep each tenant's data separate unless the datais shared. If more than one MTS is used, they may be located in closeproximity to one another (e.g., in a server farm located in a singlebuilding or campus), or they may be distributed at locations remote fromone another (e.g., one or more servers located in city A and one or moreservers located in city B). As used herein, each MTS could include oneor more logically and/or physically connected servers distributedlocally or across one or more geographic locations. Additionally, theterm “server” is meant to include a computer system, includingprocessing hardware and process space(s), and an associated storagesystem and database application (e.g., RDBMS) as is well known in theart. It should also be understood that “server system” and “server” areoften used interchangeably herein. Similarly, the databases describedherein can be implemented as single databases, a distributed database, acollection of distributed databases, a database with redundant online oroffline backups or other redundancies, etc., and might include adistributed database or storage network and associated processingintelligence.

FIG. 2 illustrates elements of MTS 16 and various interconnections inmore detail. In this example, the network interface is implemented asone or more HTTP application servers 100. Also shown is system processspace 102 including individual tenant process spaces 104, a systemdatabase 106, tenant database(s) 108 and a tenant management processspace 110. Tenant database 108 might be divided into individual tenantstorage areas 112, which can be either a physical arrangement or alogical arrangement. Within each tenant storage area 112, user storage114 might similarly be allocated for each user.

It should also be understood that each application server 100 may becommunicably coupled to database systems, e.g., system database 106 andtenant database(s) 108, via a different network connection. For example,one server 100.sub.1 might be coupled via the Internet 14, anotherserver 100.sub.N-1 might be coupled via a direct network link, andanother server 100.sub.N might be coupled by yet a different networkconnection. Transfer Control Protocol and Internet Protocol (TCP/IP) arepreferred protocols for communicating between servers 100 and thedatabase system, however, it will be apparent to one skilled in the artthat other transport protocols may be used to optimize the systemdepending on the network interconnect used.

In certain aspects, each application server 100 is configured to handlerequests for any user/organization. Because it is desirable to be ableto add and remove application servers from the server pool at any timefor any reason, there is preferably no server affinity for a user and/ororganization to a specific application server 100. In one embodiment,therefore, an interface system (not shown) implementing a load balancingfunction (e.g., an F5 Big-IP load balancer) is communicably coupledbetween the servers 100 and the user systems 12 to distribute requeststo the servers 100. In one aspect, the load balancer uses a leastconnections algorithm to route user requests to the servers 100. Otherexamples of load balancing algorithms, such as round robin and observedresponse time, also can be used. For example, in certain aspects, threeconsecutive requests from the same user could hit three differentservers, and three requests from different users could hit the sameserver. In this manner, MTS 16 is multi-tenant, wherein MTS 16 handlesstorage of different objects and data across disparate users andorganizations.

As an example of storage, one tenant might be a company that employs asales force where each salesperson uses MTS 16 to manage their salesprocess. Thus, a user might maintain contact data, leads data, customerfollow-up data, performance data, goals and progress data, etc., allapplicable to that user's personal sales process (e.g., in tenantdatabase 108). In the preferred MTS arrangement, since all of this dataand the applications to access, view, modify, report, transmit,calculate, etc., can be maintained and accessed by a user system havingnothing more than network access, the user can manage his or her salesefforts and cycles from any of many different user systems. For example,if a salesperson is visiting a customer and the customer has Internetaccess in their lobby, the salesperson can obtain critical updates as tothat customer while waiting for the customer to arrive in the lobby.

While each user's sales data might be separate from other users' salesdata regardless of the employers of each user, some data might beorganization-wide data shared or accessible by a plurality of users orall of the sales force for a given organization that is a tenant. Thus,there might be some data structures managed by MTS 16 that are allocatedat the tenant level while other data structures might be managed at theuser level. Because an MTS might support multiple tenants includingpossible competitors, the MTS should have security protocols that keepdata, applications and application use separate. Also, because manytenants will opt for access to an MTS rather than maintain their ownsystem, redundancy, up-time and backup are more critical functions andneed to be implemented in the MTS.

In addition to user-specific data and tenant-specific data, MTS 16 mightalso maintain system level data usable by multiple tenants or otherdata. Such system level data might include industry reports, news,postings, and the like that are sharable among tenants.

In certain aspects, client systems 12 communicate with applicationservers 100 to request and update system-level and tenant-level datafrom MTS 16 that may require one or more queries to database system 106and/or database system 108. MTS 16 (e.g., an application server 100 inMTS 16) generates automatically one or more SQL statements (the SQLquery) designed to access the desired information.

II. A Customizable MTS

FIG. 3 illustrates an example of objects represented as a table 300,which contains one or more data categories logically arranged as columnsor fields 303 in a viewable schema. Users can define data schemas andcreate, read, update, and delete objects within those schemas. Table 300contains an organization ID (“org id”) column 301 to distinguish tenantrows. Each row or record 305 of table 300 contains an instance of datafor each category defined by fields 303. For example, a CRM database mayinclude a table that describes a customer with fields for basic contactinformation such as name, address, phone number, fax number, etc, whichmight be included as standard categories. Another standard entity tablemay include other standard categories. In an embodiment where table 300is a standard entity, one or more fields, such as columns 303, could bestandard fields

According to one embodiment, an additional set of one or more columns,e.g., 10, 100, or 250 columns, of text data are defined in the physicalschema. These additional columns, also referred to herein as custom datacolumns, custom field columns or custom fields, allow a systemadministrator to define additional fields that are not included in thepre-defined standard fields for that entity. In one aspect, a customfield is stored out of row in a different table from table 300, althoughsuch a field may be stored in table 300, e.g. in column 310.

According to another embodiment, table 300 may be a custom entityobject, which may have no standard fields. In this case, table 300 mayinclude multiple custom tables, such as entity 360. In this case, table300 contains a primary key (e.g., “custom entity id” 301) thatidentifies those rows throughout the database. These custom entities mayextend a base application or integrate with other systems, and may becreated to specifically cater to, and to facilitate data storage andretrieval for, that organization's particular business model. Thus,table 300 may contain multiple logical tables per organization. A row inthese custom entities may be linked to another row of the custom entitytable or of a standard entity table. For example, an asset object can bea child custom object of an account object.

Custom fields and custom entities are described in further detail in apublished U.S. Pat. No. 7,779,039 (U.S. application Ser. No.10/817,161), entitled “CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANTDATABASE SYSTEM,” which is incorporated in its entirety by referenceherein for all purposes.

III. Formulas in a Customizable MTS

In an embodiment, users can define data schemas and create, read,update, and delete objects within those schemas, including customfields. In this context, a formula is an extension of the schema, which,for example, may specify how to compute a new custom field from otherfields. Formulas are expressions that take certain values as input andproduce at least one result. Formulas may include arithmeticexpressions, but may also include, for example, textual, conditional, orother logical expressions. An example of a textual expression is theconcatenating of two strings, such as in formula 313. A single formulamay include one type of expression or many types of expressions.

According to different embodiments, formulas may be used for manydifferent purposes. Formulas may receive many different types of inputsand may provide many different types of results. For example, formulasmay produce Boolean, date, date/time, duration, text, or hyperlinkresults. In some embodiments, the result of the formula may be used asthe value placed as an entry in a specific row of a field or used todetermine an action.

A. Formulas for Calculating Custom Fields

In one embodiment, a customizable field is created such that its valueis based on the values within other fields. A formula may be used todefine the value of a particular field or column, and the input data tothe formula may come from other columns. For example, formulas may beused to compute a discount price from a base price and a discountpercent, to compute the sum of purchases, or to compute a net profitbased on retail cost and wholesale cost. A formula may also return a“null” value. This may be necessary should organizations have need forenforcing a “null” value in a field, based on the value of anotherfield. For example, to enforce “Do Not Call” registries, an organizationmay need to null out the standard Phone field on the contact record.Formulas in column 310 show some examples of different formulas.

In one aspect, a formula may only use input data from fields within thesame row. For example, formula 311 only accesses data within the firstrow. Evaluation of formula 311 uses data A0 and A3 as inputs to obtainthe result AN, which is used as the value for the custom field. Suchformulas are termed one-row formulas. It is noteworthy that in anembodiment, the formula need not exist in the same row as the data thatit accesses. For instance, the formula BN=A0+A1 could be automaticallyupdated synchronously. The same formula may be used for other columnentries, but using the corresponding data from that particular row, suchas formula 312.

In an embodiment, formulas may also access data from more than one row.For example, formula 317 accesses data from each of the first 3 rows,i.e. A2, B2, and C2. Such formulas are termed multiple-row formulas.Multiple-row formulas typically occur as a summary field that aggregatesor averages the values of a specific column. However, multiple-rowformulas may have input data from different fields including a fieldfrom a child custom object. For example, a formula field of a parentobject may access rows of one of its children and a formula in a row ofa custom entity may access data in a row of another custom entity.

In an embodiment, a formula may also use as input the current entryvalue for which the result of the formula is used, i.e. the formula mayhave input from the same field being updated. For example, if a currencyfield “Amount” needs to be updated to a new value using a mathematicalformula, all currency fields on the record should be available fordetermining the new value, including the “Amount” field itself (i.e.,Amount=Amount*2), as in formula 314. When a formula is used to update anentry, i.e., the value of a specific row (record) and field (column),the formula may be termed a custom formula field.

In an embodiment, a formula may be evaluated in response to differentactions. For example, a formula may be evaluated based on the creationof a record, a change to input data, or based on an action in a workflowthat occurs at a specific time.

In an embodiment, a formula that is used to determine default values fora field when a new record is created is termed a default formula. Apurpose of a default formula is to enhance user productivity by reducingthe number of fields a user needs to fill in manually. Typically, globalvalues, such as those for an organization or custom entity, are used asthe input, but values specific to a certain record may also be used. Adefault value could be Null. A default formula is executed after thefield is created, e.g. by clicking a “New” button, and before the editpage is displayed. Thus, editable fields on the page are populated withvalues before presenting the page to the user. The values may then bestored in the database. Default value formulas use the same formulaexpression language as custom formula fields. However, default valueformulas are only calculated once at the very first time the record isinitialized. The user can override the calculated default value if theychoose. In one embodiment, if the user blanks out the calculated defaultvalue, there is no way to get the value back. In other embodiments, auser may be able to re-create the value.

In an embodiment, a workflow field formula allows organizations toupdate the value of a field as a result of a workflow rule, condition,or trigger. For example, when a specific condition is approved, theformula is then stored in a custom field at its current value. It is notupdated if the fields that are used in the formula change. An example isthe price of an order, which should not change after the order has beenplaced. The condition may be an external input such as entered by auser, or based on a certain value of an entry stored within thedatabase. A single condition may act as a trigger to update multiplefields. In some embodiments, the amount of fields updatable by a singlerule is capped at a maximum amount.

B. Validation Formulas

In another embodiment, formulas are used as part of a decision scheme,where the result is whether an action is performed or not. For example,in one aspect, a formula is used to determine whether to return True(Valid) or False (Error), such as in an if-then statement. The Booleanresult then may determine whether a requested action is performed on afield, file, or other object. Such formulas are termed validationformulas. Other Boolean values may also be used.

In one aspect, the formula is composed of multiple expressions, each ofwhich has a specified value (e.g. equals) or range of values (e.g.greater than) for a true value to be returned. In another aspect, acertain percentage or combination of expressions have a specified valueor range of values for a true value to be returned. Conversely, aformula may use the results of expressions to determine if a false valueis to be returned. The formula expression language for validationformulas generally follows the same rules as custom formula fields.Formula 319 shows an example of a validation formula. Note that the trueor false result is not used as the formula field value, but is used todetermine whether the action is performed.

In one aspect, a validation formula is executed when the action isrequested, but before the action is actually performed. If thevalidation formula returns a False (Error) or improper value, ause-specified error message may be displayed. In one aspect, the errormessage may be displayed next to a standard or custom field. Thus,field-specific validation logic can stop or abort the requested actionfrom occurring and/or display an error message if appropriate. Inanother aspect, an error message may be displayed at the top of the pagefor validation logic that is not specific to any one field. Anadministrator may specify the error message to be displayed, as well aswhere to display the error message as part of the validation definitionprocess. If the formula returns True (Valid), the requested action maybe allowed to continue normally. In one embodiment, a validation formulais used to determine whether a save request is to be performed orcompleted and/or to display an error message regarding the save request.

A validation formula definition may include a name and a statusindicator. A validation name is similar to a custom object name or fieldname. An active (Status) indicator, e.g. a checkbox, specifies whetherthe validation formula is active or inactive. Only active validationformulas are executed when the action is requested. Validation formulasmay be active by default. A description of the validation formula may beused for documentation purposes. Error messages can be stored in such away that they are available in a manner similar to field labels.

A validation formula is able to reference any merge field on the currententity, just like a custom formula field. In one aspect, validationformulas are not associated with a specific record type. In this case,validation formulas can use a merge field in the formula expression toimplement record type-specific functionality. Other embodiments havesubtype-specific validation formulas. In one embodiment, if the fieldassociated with the formula is hidden or read-only, the validation isstill performed, but any errors are displayed at the top of the page,instead of highlighting the field.

IV. Evaluating Formulas in a Customizable MTS

In an MTS where a large amount of data from many different tenants maybe stored in a plurality of different ways, computational resources maybe constrained. For this reason, it may be beneficial for differenttypes of formulas to be treated differently. Thus, embodiments identifyformulas whose computational requirements are different and respond byutilizing an appropriate amount of resources, which may be dependent onmany factors.

FIG. 4 shows a set of categories 400 that are used for formulaevaluation according to one embodiment. The categories 400 may apply toall of the formulas mentioned above. Formulas 405 may initially beseparated into two types.

The first type of formula is a one-row formula 410 that accesses data inonly one row as described above. These formulas are short-running andare evaluated with a synchronous update 420. For example, evaluation ofa simple arithmetic expression over fields in the same record areshort-running The synchronous evaluation ensures that the field valuesare always up to date.

Another type of formula is a multiple-row formula 415, which accessesdata in more than one row as described above. Formulas 415 arepotentially long running Multiple-row formulas 415 may be further brokendown into delta formulas 425 that are updatable by a delta value andcomplex formulas 430 that are not updatable with a delta value. Deltaformulas 425 are evaluated with a synchronous update 435. Complexformulas 430 may be evaluated synchronously or asynchronously dependingon certain factors.

FIG. 5 illustrates a method 500 for evaluating formulas in a databasesystem according to one embodiment. In block (505), a formula isdefined. Part of the definition includes which data the formulaaccesses. In one aspect, the formula uses the data as input to obtain afirst result. In block (510), a first result is obtained from a firstevaluation of the formula. In block (515), a change in at least oneinput of the formula is received.

In block (520), a determination is made as to whether the formulaaccesses data from more than one row of a single database table. In oneaspect, an analysis of the properties of the input data of the formulais made at this point in order to make the determination. In anotheraspect, the determination is made by retrieving stored informationregarding the properties of the input data. The stored information maybe obtained from a previous analysis or from data entered by a user. Inembodiments, this may be achieved with a flag or data byte indicatingthe kind of formula.

In block (525), if the formula accesses data from only one row, theone-row formula is synchronously evaluated to obtain a second result. Inblock (530), if the formula accesses data from more than one row, adecision is made as to whether to evaluate the multiple-row formulasynchronously or asynchronously to obtain the second result.

A. Short-Running Formulas

In one aspect, the one-row formulas are evaluated on-the-fly at thepoint the formula is referenced, e.g. when a custom field is viewed.Such formulas may be referenced in two contexts, and may be compileddown into separate forms for each context.

The first context is the “point-wise” context, such as the edit/detailpage for a single object. In this case, formula evaluation may occur inthe application to reduce the load on the database. In one aspect, astack machine-based set of commands that can be executed by theapplication are created.

The second context is the “bulk” context, such as a list view for a setof objects satisfying certain conditions. In this case, formulaevaluation may occur in the database so the list can be efficientlysorted and managed along the formula field. In one aspect, a queryfragment for evaluating the formulas is generated and merged intoqueries for the objects. The generated query fragment may defineadditional fields that contain the values of formulas. The semantics ofthe formulas should be carefully chosen so that the same result can beobtained in both contexts.

In one aspect, the decision of whether to evaluate the formula in “bulk”is decided based on functionality. Effectively, this means that oncesomeone wants to view multiple rows of a field, where each field dependsonly on fields within the same row, then the calculation is done inbulk. For example, reports that consolidate information across manyaccounts are typically done in bulk. In one aspect, reports canintegrate data from sales, marketing, and service. In another aspect,reports access standard account and contact information such as new,active, and neglected accounts, contact roles, partner accounts, andaccount teams. In yet another aspect, reports also organize data bydate, team, product, type, status, and many other criteria.

Error handling within a bulk evaluation can be problematic. If a formulaproduces an error, such as divide-by-zero, for some elements of thebacking data, then the entire query could fail. In one aspect, theelements causing the problem are identified and flagged; and results forthe remaining elements are returned. In another aspect, to guard againsterrors in the generated query fragment, the value may be forced to NULL;and an additional field describing which elements had errors is defined.For example, the formula “1/x” would produce a query fragment equivalentto “if x< >0 then 1/x else NULL” together with an additional fielddefined by the fragment “x< >0”.

B. Multiple-Row Formulas Computable with Delta

In one embodiment, a result from a multiple-row formula is stored in thedatabase. Subsequent references of these formulas simply retrieve thevalue from the database. In one aspect, updating of the value resultingfrom a formula occurs only if the backing (input) data has changed.Thus, database resources are not wasted doing needless work, as would bethe case if formula values were updated at regular intervals.

One type of multiple-row formula is a “delta” formula. A “delta” is thedifference between the old value and the new value. Delta formulas areformulas that can be computed as a delta added to or subtracted from thestored value. For example, consider a formula field on a parent objectthat takes the sum (of a field) across all its children objects. Theupdate of a child can be processed by computing the new value minus theold value and adding it to the stored value of the sum.

In one embodiment, formulas in this group are evaluated synchronously atthe point the backing data is changed. The delta is computed from thechange and merged into the stored value in the database. This ensuresthat the results are always up to date. As these formulas are alsoupdated synchronously, they may be short-running.

C. Evaluating Potentially Long-Running Multiple-Row Formulas

Other types of multiple-row formulas are more complex and arepotentially long-running In one embodiment, the categorization of theseformulas is done dynamically, and thus it may not be known whether aformula is short or long running In this case, the implementationtechnique performs its first actions at the point the backing data ischanged. Techniques used in evaluating these formulas includedetermining whether to evaluate them synchronously or asynchronously,determining how the asynchronous evaluation of the formulas is done, andtracking a time when a field defined by a formula was last correct.

FIG. 6 illustrates a method 600 for updating a formula in a databaseaccording to an embodiment. In block (605), a request to update aformula is received. In one aspect, the request is created automaticallyafter backing data has changed. In another aspect, the request isinitiated directly by a user.

In block (610), a query is submitted that includes a set of criteria.The set may include one criterion or multiple criteria. In block (615),the criteria is analyzed to determine whether it is satisfied. In block(620), if the criteria are satisfied, the formula is updatedsynchronously. In block (625), if the criteria are not satisfied, theformula is updated asynchronously.

The set of criteria may be one criterion or may be multiple criteria.The criteria may be based on many different properties, e.g. inputs ofthe formula, attributes of a user, or the database usage. If multiplecriteria are used, the criteria may be satisfied based on any expressionusing the criteria. For example, in one aspect all of the criteria maybe required to be satisfied, or in other aspects only some of thecriteria or certain combinations of the criteria may be required to besatisfied. One skilled in the art will recognize the many differenttypes of combinations of criteria that may be used.

In one embodiment, the set of criteria includes a test of how muchbacking data the formula has. If the formula is backed by a small amountof data, the formula will be updated synchronously. In one aspect, theformula is evaluated in a query with a limit on the number of backingdata elements. If this query succeeds, the result may be stored in thedatabase at the point the backing data is changed. This ensures that theresults are always up to date. In another embodiment, the placement ofthe backing data is considered. For example, if the backing data comesfrom only two rows then the evaluation may be synchronous, whereas ifthe backing data is more disperse then the evaluation may beasynchronous.

In other embodiments, the current performance load of the database isused. For instance, if resources that are allocated for other purposeshave been deemed to have a higher priority, then an update of a formulamay be done asynchronously. Thus, the current load on the databasesystem may be assessed. Other criteria include a number of synchronousevaluations per user or tenant, which in one aspect could cause anasynchronous evaluation if a maximum was reached. Each of the criteriamay be combined, or used individually, in the determination of whetherto asynchronously evaluate a formula. For example, the exact number ofbacking data along with its positions may be weighed against the currentusage of resources.

FIG. 7 illustrates a method 700 for updating a formula asynchronouslyaccording to an embodiment. In one aspect, method 700 is used toaccomplish the asynchronous update in block (625). In optional block(705), the rate at which requests for an update can fail and wasteresources is controlled. To this end, in one aspect, a window ofhistorical information is kept in memory for the application. If anattempt for a synchronous update fails, subsequent attempts to update aformula for the same object and field are blocked for some period oftime. This historical information need not be highly-available orhighly-accurate since it is not needed for correctness.

In block (710), if an attempt at a synchronous update fails, thuscausing an asynchronous update, the requested update of a formula isadded as an item to a persistent queue. In one aspect, this item canrecord the fact that a given field on a given object must be recomputed.

In an asynchronous update, the stored value of a formula field may betemporarily inconsistent with the backing data, and thus stale. In oneembodiment, an indication of staleness is provided, such as in block(715). In one aspect, a user-visible flag indicates that the fields ofan object are stale. Also, a rough estimate of the last time the valuesof a field were fresh may be provided. For efficiency, the granularityof this information may be at the level of the entire object rather thanindividual fields, but flags for individual fields and even recordswithin a field may be used if granularity is desired.

In one embodiment, a staleness indicator is computed by using a counterfield for an object, field, or entry within a field. The counter fieldkeeps a count of the number of items in the queue for that object. Inone aspect, the counter field may be hidden. This counter field isincremented when an item is added to the queue at the point the backingdata is changed and is decremented when an item is removed from thequeue at the point the value of the field is recomputed. The stalenessindicator is computed by checking whether this count field is greaterthan zero. In one aspect, the staleness indicator is an on-screen flag.Other embodiments may have other staleness indicators, including icons,shading, and links to status info.

In block (720), other items that had been previously added in the queueare evaluated. In one aspect, a set of batch servers asynchronouslydequeue these items. In block (725), the formula for the item added inblock (710) is evaluated. Thus, where the formula provides the values ofa field, one or more of these values are recomputed. In block (730), theresult is stored in the database.

FIG. 8 illustrates a method 800 for computing the staleness indicatorand an estimate of the last time the fields of an object were freshduring an asynchronous update of formulas for the fields according toone embodiment. In block (805), a counter field that counts the numberof items of an object or field in a queue is provided. In block (810),an estimate field is provided. In one aspect, the counter and/orestimate fields are hidden. In block (815), a change time at which thebacking data of a formula changed and an indication that the field needsto be updated is associated with a first queue item. In one aspect, thechange time and indication of a need for an update are stored in thefirst queue item.

In block (820), when the first item belonging to an object is added tothe queue, the change time is copied into the estimate field of theobject and the counter field is incremented from 0 to 1. In one aspect,the items in the queue are ordered by update time, and the queue itemsare processed in order by batch servers. In block (825), additionalitems for the same object, or field, are added to the queue and thecounter field is incremented; however, the change time is not copied tothe estimate time for these additional items. In block (830), at thepoint an item is de-queued and processed, the change time for that itemis copied into the estimate field on the object and the counter field isdecremented.

Note that this estimate is actually off by one change. That is, after anitem is processed, the object is current up to the time of the nextchange in the queue. For example, after the first item is processed, theestimate field already has the change time of the first item as itsvalue, and thus the value does not change when the first item isde-queued and evaluated. However, this inaccuracy is safe in that itmakes the estimate field values look worse than they are. Itconsiderably improves efficiency because there is no need to scanthrough the items of the queue. No special processing is needed when thelast item is de-queued because the count field indicates that the objectis not stale.

While the invention has been described by way of example and in terms ofthe specific embodiments, it is to be understood that the invention isnot limited to the disclosed embodiments. To the contrary, it isintended to cover various modifications and similar arrangements aswould be apparent to those skilled in the art. Therefore, the scope ofthe appended claims should be accorded the broadest interpretation so asto encompass all such modifications and similar arrangements.

1. A method of processing a request for a field of one of the tables of a database of a database system, the method comprising: receiving a request for an action associated with the field, the action triggered as part of a workflow; based on the workflow-triggered action, evaluating a workflow field formula associated with the field, the formula being specific to the field, and updating the field to a current value; and preventing a subsequent reevaluation of the workflow field formula from updating the field when values of input fields used in the workflow field formula change.
 2. The method of claim 1, wherein the workflow-triggered action corresponds to an approval.
 3. The method of claim 1, wherein the workflow-triggered action corresponds to placing an order, and wherein the field is a price of the order.
 4. The method of claim 1, wherein the workflow-triggered action corresponds to a result of a certain value being entered into the database.
 5. The method of claim 1, further comprising: based on the workflow-triggered action, evaluating one or more additional formulas to obtain one or more additional custom field values; and preventing a subsequent evaluation of the one or more additional formulas from obtaining new custom field values when input values for the one or more additional formulas change.
 6. The method of claim 4, wherein the number of additional custom field values to be obtained based on the workflow-triggered action is capped at a maximum amount.
 7. A non-transitory computer readable medium storing program code for controlling a processor to perform an operation for processing a request for a field of one of the tables of a database of a database system, the program code comprising code for: receiving a request for an action associated with the field, the action triggered as part of a workflow; based on the workflow-triggered action, evaluating a workflow field formula associated with the field, the formula being specific to the field, and updating the field to a current value; and preventing a subsequent reevaluation of the workflow field formula from updating the field when values of input fields used in the workflow field formula change.
 8. A system comprising: a database system that includes a database and at least one database table, wherein the database table includes a field; at least one computer processor coupled with the database, the computer processor configured to: receive a request for an action associated with the field, the action triggered as part of a workflow; based on the workflow-triggered action, evaluate a workflow field formula associated with the field, the formula being specific to the field, and updating the field to a current value; and prevent a subsequent reevaluation of the workflow field formula from updating the field when values of input fields used in the workflow field formula change. 